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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document shall provide a description of the UTRAN lur and lub interfaces user plane protocols for 
Dedicated Transport Channel data streams as agreed within the TSG-RAN working group 3. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TS 25.301: "Radio Interface Protocol Architecture". 
[2] 3GPP TS 25 .40 1 : "UTRAN Overall Description" . 

[3] 3GPP TS 25.302: "Services provided by the Physical Layer". 

[4] 3GPP TS 25.433: "UTRAN lub interface NBAP signalHng". 

[5] 3GPP TS 25.402: "Synchronization in UTRAN, Stage 2". 

[6] 3GPP TS 25.423: "UTRAN lur interface RNSAP signalling". 

[7] 3GPP TS 25.215: "Physical layer - Measurements (FDD)". 

[8] 3GPP TS 25 .225 : "Physical layer - Measurements (TDD)" . 

[9] 3GPP TS 25.212: "Multiplexing and channel coding (FDD)". 

[10] 3GPP TS 25.222: "Multiplexing and channel coding (TDD)". 

[II] 3GPP TS 25 .224: "Physical Layer Procedures (TDD)" . 

3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Transport Bearer: service provided by the transport layer and used by Frame Protocol for the delivery of FP PDU 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

CFN Connection Frame Number 

CRC Cyclic Redundancy Checksum 

CRCI CRC Indicator 

DCH Dedicated Transport Channel 
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DL Downlink 

DSCH Downlink Shared Channel 

DTX Discontinuous Transmission 

FP Frame Protocol 

FT Frame Type 

LTOA Latest Time of Arrival 

PC Power Control 

QE Quality Estimate 

TB Transport Block 

TBS Transport Block Set 

TFI Transport Format Indicator 

TFCI Transport Format Combination Indicator 

ToA Time of Arrival 

ToAWE Time of Arrival Window Endpoint 

ToAWS Time of Arrival Window Startpoint 

TTI Transmission Time Interval 

UL Uplink 



General aspects 



The specification of lub DCH data streams is also valid for Im DCH data streams. 

The complete configuration of the transport channel is selected by the SRNC and signalled to the Node B via the lub 
and lur control plane protocols. 

The parameters of a Transport channel are described in [1]. Transport channels are multiplexed on the downlink by the 
Node B on radio physical channels, and de-multiplexed on the uplink from radio physical channels to Transport 
channels. 

In lur interface, every set of coordinated Transport channels related to one UE context that is communicated over a set 
of cells that are macro-diversity combined within Node B or DRNC, is carried on one transport bearer. This means that 
there are as many transport bearers as set of coordinated Transport channels and lur User ports for that communication. 

In lub interface, every set of coordinated Transport channels related to one UE context that is communicated over a set 
of cells that are macro-diversity combined within Node B is carried on one transport bearer. This means that there are as 
many transport bearers as set of coordinated Transport channels and lub User ports for that communication. 

Bi-directional transport bearers are used. 

4.1 DCH FP services 

DCH frame protocol provides the following services: 
Transport of TBS across lub and lur interface. 

Transport of outer loop power control information between the SRNC and the Node B. 
Support of transport channel synchronization mechanism. 
Support of Node Synchronization mechanism. 
- Transfer of DSCH TFI from SRNC to Node B. 

Transfer of Rx timing deviation (TDD) from the Node B to the SRNC. 
Transfer of radio interface parameters from the SRNC to the Node B. 
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4.2 Services expected from the Data Transport Network layer 

Following service is required from the transport layer: 

- Delivery of FPPDU. 

In sequence delivery is not required. However, frequent out-of-sequence delivery may impact the performance and 
should be avoided. 

4.3 Protocol Version 

This revision of the specification specifies version 1 of the protocol. 

5 DCH Frame Protocol procedures 

5.1 Data Transfer 
5.1.0 General 

When there is some data to be transmitted, DCH data frames are transferred every transmission time interval from the 
SRNC to the Node B for downlink transfer, and from Node B to the SRNC for uplink transfer. 

An optional error detection mechanism may be used to protect the data transfer if needed. At the transport channel setup 
it shall be specified if the error detection on the user data is used. 



5.1.1 Uplink 



NB 



SRNC 



UL DATA FRAME ^ 



Figure 1 : Uplink Data Transfer procedure 

Two modes can be used for the UL transmission: normal mode and silent mode. The mode is selected by the SRNC 
when the transport bearer is setup and signalled to the Node B with the relevant control plane procedure. 

- In normal mode, the Node B shall always send an UL DATA FRAME to the RNC for all the DCHs in a set of 
coordinated DCHs regardless of the number of Transport Blocks of the DCHs. 

In silent mode and in case only one transport channel is transported on a transport bearer, the node-B shall not 
send an UL DATA FRAME to the RNC when it has received a TFI indicating "number of TB equal to 0" for the 
transport channel during a TTI. 

In silent mode and in case of coordinated DCHs, when the Node B receives a TFI indicating "number of TB 
equal to 0" for all the DCHs in a set of coordinated DCHs, the Node B shall not send an UL DATA FRAME to 
the RNC for this set of coordinated DCHs. 

For any TTI in which the Node B Layer 1 generated at least one CPHY-Out-of-Sync-IND primitive, the Node B is not 
required to send an UL DATA FRAME to the SRNC. 

When Node B receives an invalid TFCI, no Data Frame shall be sent to the SRNC. 
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5.1.2 Downlink 



NB 



SRNC 



PL DATA FRAME 



Figure 2: Downlink Data Transfer procedure 

The Node B shall only consider a transport bearer synchronised after it has received at least one data frame on this 
transport bearer before LTOA [5]. 

The Node B shall consider the DL user plane for a certain RL synchronised if all transport bearers established for 
carrying DL DCH DATA FRAMEs for this RL are synchronised. 

[FDD - Only when the DL user plane is considered synchronised, the Node B shall transmit on the DL DPDCH. 

[TDD - The Node B shall transmit special bursts on the DL DPCH as per [11], until the DL user plane is considered 
synchronised] . 

When the DL user plane is considered synchronised and the Node B does not receive a valid DL DATA FRAME in a 
TTI, it assumes that there is no data to be transmitted in that TTI for this transport channel, and shall act as one of the 
following cases: 

[TDD - If the Node B receives no valid data frames for any transport channel assigned to a UE it shall assume 
DTX and transmit special bursts as per [11]]. 

If the Node B is aware of a TFI value corresponding to zero bits for this transport channel, this TFI is assumed. 
If the TFS contains both a TFI corresponding to "TB length equal to bits" and a TFI corresponding to "number 
of TB equal to 0", the Node B shall assume the TFI corresponding to "number of TB equal to 0". When 
combining the TFI's of the different transport channels, a valid TFCI might result and in this case data shall be 
transmitted on Uu. 

If the Node B is not aware of a TFI value corresponding to zero bits for this transport channel or if combining 
the TFI corresponding to zero bits with other TFI's, results in an unknown TFI combination, the handling as 
described in the following paragraph shall be applied. 

At each radio frame, the Node B shall build the TFCI value of each CCTrCH, according to the TFI of the DCH data 
frames multiplexed on this CCTrCH and scheduled for that frame. [FDD - In case the Node B receives an unknown 
combination of TFIs from the DL DATA FRAME s, it shall transmit only the DPCCH without TFCI bits.] [TDD - In 
case the Node receives an unknown combination of DCH data frames, it shall apply DTX, i.e. suspend transmission on 
the corresponding DPCHs.] 



5.2 Timing Adjustment 



The Timing Adjustment procedure is used to keep the synchronization of the DCH data stream in DL direction, i.e to 
ensure that the Node B receives the DL frames in an appropriate time for the transmission of the data in the air 
interface. 

SRNC always includes the Connection Frame Number (CFN) to all DL DCH FP frames. The same applies to the DSCH 
TFI SIGNALLING control frame. 

If a DL DATA FRAME or a DSCH TFCI SIGNALLING control frame arrives outside the arrival window defined in 
the Node B, the Node B shall send a TIMING ADJUSTMENT control frame, containing the measured ToA and the 
CFN value of the received DL DATA FRAME. 
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NB 



SRNC 



TIMING ADJUSTMENT 



Figure 3: Timing Adjustment procedure 

The arrival window and the time of arrival are defined as follows: 

Time of Arrival Window Endpoint (ToAWE): ToAWE represents the time point by which the DL data shall arrive to 
the node B from lub. The ToAWE is defined as the amount of milliseconds before the last time point from which a 
timely DL transmission for the identified CFN would still be possible taking into account the node B internal delays. 
ToAWE is set via control plane. If data does not arrive before ToAWE a TIMING ADJUSTMENT control frame shall 
be sent by node B. 

Time of Arrival Window Startpoint (ToAWS): ToAWS represents the time after which the DL data shall arrive to 
the node B from lub. The ToAWS is defined as the amount of milliseconds from the ToAWE. ToAWS is set via control 
plane. If data arrives before ToAWS a TIMING ADJUSTMENT control frame shall be sent by node B. 

Time of Arrival (ToA): ToA is the time difference between the end point of the DL arrival window (ToAWE) and the 
actual arrival time of DL frame for a specific CFN. A positive ToA means that the frame is received before the 
ToAWE, a negative ToA means that the frame is received after the ToAWE. 

The general overview on the Timing Adjustment procedure is reported in [2]. 



5.3 DCH Synchronisation 



Synchronisation procedure is used to achieve or restore the synchronisation of the DCH data stream in DL direction, 
and as a keep alive procedure in order to maintain activity on the lur/Iub transport bearer. 

The procedure is initiated by the SRNC by sending a DL SYNCHRONISATION control frame towards Node B. This 
control frame indicates the target CFN. 

Upon reception of the DL SYNCHRONISATION control frame. Node B shall immediately respond with UL 
SYNCHRONISATION control frame indicating the ToA for the DL SYNCHRONISATION control frame and the 
CFN indicated in the received DL SYNCHRONISATION control frame. 

UL SYNCHRONISATION control frame shall always be sent, even if the DL SYNCHRONISATION control frame is 
received by the Node B within the arrival window. 



NB 



SRNC 



DL SYNCHRONISATION 



UL SYNCHRONISATION 

► 



Figure 4: DCIH Synchronization procedure 



5.4 Outer Loop PC Information Transfer [FDD] 

Based, for example, on the CRCI values and on the quality estimate in the UL frames, SRNC modifies the SIR target 
used by the UL Inner Loop Power Control by including the absolute value of the new SIR target in the OUTER LOOP 
PC control frame sent to the Node B's. 
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At the reception of the OUTER LOOP PC control frame, the Node B shall immediately update the SIR target used for 
the inner loop power control with the specified value. 

The OUTER LOOP PC control frame can be sent via any of the transport bearers dedicated to one UE. 



NB 



SRNC 



OUTER LOOP PC 



Figure 5: Outer Loop Power Control Information Transfer procedure 



5.5 Node Synchronisation 



The Node Synchronisation procedure is used by the SRNC to acquire information on the Node B timing. 

The procedure is initiated by the SRNC by sending a DL NODE SYNCHRONISATION control frame to Node B 
containing the parameter TL 

Upon reception of a DL NODE SYNCHRONISATION control frame, the Node B shall respond with UL NODE 
SYNCHRONISATION control frame, including the parameters T2 and T3, as well as the Tl which was indicated in the 
initiating DL NODE SYNCHRONISATION control frame. 

The Tl, T2, T3 parameters are defined as: 

Tl: RNC specific frame number (RFN) that indicates the time when RNC sends the frame through the SAP to the 
transport layer. 

T2: Node B specific frame number (BEN) that indicates the time when Node B receives the correspondent DL 
SYNCHRONISATION control frame through the SAP from the transport layer. 

T3: Node B specific frame number (BEN) that indicates the time when Node B sends the frame through the SAP to 
the transport layer. 

The general overview on the Node Synchronisation procedure is reported in [2]. 



NB 



SRNC 



DL NODE SYNCHRONISATION 



IJL NODE SYNCHRONISATION 



Figure 6: Node Synchronisation procedure 



5.6 Rx Timing Deviation IVIeasurement [TDD] 

In case the Timing Advance Applied IE indicates "Yes" (see [4]) in a cell, the Node B shall, for all UEs using DCHs, 
monitor the receive timing of the uplink DPCH bursts arriving over the radio interface, and shall calculate the Rx 
Timing Deviation. If the calculated value, after rounding, is not zero, it shall be reported to the SRNC in a RX TIMING 
DEVIATION control frame belonging to that UE. Eor limitation of the frequency of this reporting, the Node B shall not 
send more than one RX TIMING DEVIATION control frame per UE within one radio frame. 

If the Timing Advance Applied IE indicates "No" (see [4]) in a cell, monitoring of the receive timing of the uplink 
DPCH bursts is not necessary and no RX TIMING DEVIATION control frame shall be sent. 
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NB 



SRNC 



RX TIMING DEVIATION 

► 



Figure 7: Rx Timing Deviation lUleasurement procedure 



5.7 DSCH TFCI Signalling [FDD] 



This procedure is used in order to signal to the node B the TFCI (field 2). This allows the node B to build the TFCI 
word(s) which have to be transmitted on the DPCCH. A transport bearer of any DCH directed to this same UE may be 
employed for transport over the lub/Iur. 

The procedure consists in sending the DSCH TFCI SIGNALLING control frame from the SRNC to the node B. The 
frame contains the TFCI (field 2) and the correspondent CFN. The DSCH TFCI SIGNALLING control frame is sent 
once every Uu frame interval (10 ms) for as long as there is DSCH data for that UE to be transmitted in the associated 
PDSCH Uu frame. In the event that the node B does not receive a DSCH TFCI SIGNALLING control frame then the 
node B shall infer that no DSCH data is to be transmitted to the UE on the associated PDSCH Uu frame and will build 
the TFCI word(s) accordingly. 



NB 



SRNC 



DSCH TFCI SIGNALLING 



Figure 8: DSCH TFCI Signalling procedure 



5.8 Radio Interface Parameter Update [FDD] 

This procedure is used to update radio interface parameters which are applicable to all RL's for the concerning UE. Both 
synchronised and unsynchronised parameter updates are supported. 

The procedure consists of a RADIO INTERFACE PARAMETER UPDATE control frame sent by the SRNC to the 
Node B. 



NB 



SRNC 



^RADIO INTERFACE 



PARAMETER UPDATE 



Figure 9: Radio Interface Parameter Update procedure 

If the RADIO INTERFACE PARAMETER UPDATE control frame contains a TPC Power Offset value, the Node B 
shall apply the newly provided TPC PO as soon as possible in case no CFN is included or from the indicated CFN. 



5.9 Tinning Advance [TDD] 



This procedure is used in order to signal to the Node B the adjustment to be performed by the UE in the uplink timing. 
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The Node B shall use the CFN and timing adjustment values to adjust its layer 1 to allow for accurate impulse 
averaging. 



NB 



SRNC 



TIMING ADVANCE 



Figure 9A: Timing Advance procedure 



5.10 General 

5.10.1 Transport bearer replacement 

As described in NBAP [4] and RNSAP [6], transport bearer replacement can be achieved by using the Synchronised 
Radio Link Reconfiguration Preparation procedure in combination with the Synchronised Radio Link Reconfiguration 
Commit procedure, or by using the Unsynchronised Radio Link Reconfiguration procedure. In both cases the following 
steps can be discerned: 

1) The new transport bearer is established after which 2 transport bearers exist in parallel. 

2) The transport channel(s) is/are switched to the new transport bearer. 

3) The old transport bearer is released. 

In step 1), communication on the old transport bearer continues as normal. In addition, the Node-B shall support the 
Synchronisation procedure (see subclause 5.3) on the new bearer. This enables the SRNC to determine the timing on the 
new transport bearer. 

Regarding step 2), the moment of switching is determined differently in the synchronised and unsynchronised case: 

When using the combination of the Synchronised Radio Link Reconfiguration Preparation procedure and the 
Synchronised Radio Link Reconfiguration Commit procedure, the UL/DL data frames shall be transported on the 
new transport bearer from the CFN indicated in the RL RECONFIGURATION COMMIT message. 

When using the Unsynchronised Radio Link Reconfiguration procedure, the Node-B shall start using the new 
transport bearer for the transport of UL data frames from the CFN at which the new transport bearer is 
considered synchronised (i.e. has received a DL data frame before LTOA [4]). 

In both cases, starting from this CFN the Node-B shall support all applicable DCH frame protocol procedures on the 
new transport bearer and no requirements exist regarding support of DCH frame protocol procedures on the old 
transport bearer. 

Finally in step 3), the old transport bearer is released. 
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Frame structure and coding 



6.1 General 

The general structure of a DCH FP frame consists of a header and a payload. The structure is depicted in figure 9B. 



Header 


Payload 



Figure 9B: General structure of a frame protocol PDU 

The header contains a CRC checksum, the frame type field and information related to the frame type. 

There are two types of DCH FP frames (indicated by the Frame Type field): 

- DCH data frame. 

DCH control frame. 

The payload of the data frames contains radio interface user data, quality information for the transport blocks and for 
the radio interface physical channel during the transmission time interval (for UL only), and an optional CRC field. 

The payload of the control frames contains commands and measurement reports related to transport bearer and the radio 
interface physical channel but not directly related to specific radio interface user data. 

6.1 .1 General principles for the coding 

In the present document the structure of frames will be specified by using pictures similar to figure 10. 



7 6 5 



1 



Field 1 


Field 2 


Field 3 


Field3(cont.) 


Field 4 


Spare Extension 





Byte 1 
Byte 2 
Byte 3 



Figure 10: Example of notation used for the definition of the frame structure 

Unless otherwise indicated, fields which consist of multiple bits within a byte will have the more significant bit located 
at the higher bit position (indicated above frame in figure 10). In addition, if a field spans several bytes, more significant 
bits will be located in lower numbered bytes (right of frame in figure 10). 

On the lub/Iur interface, the frame will be transmitted starting from the lowest numbered byte. Within each byte, the 
bits are sent according decreasing bit position (bit position 7 first). 
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The parameters are specified giving the value range and the step (if not 1). The coding is done as follows (unless 
otherwise specified): 

Unsigned values are binary coded. 

Signed values are coded with the 2's complement notation. 

Bits labelled "Spare" shall be set to zero by the transmitter and shall be ignored by the receiver. The Spare Extension 
indicates the location where new lEs can in the future be added in a backward compatible way. The Spare Extension 
shall not be used by the transmitter and shall be ignored by the receiver. 

6.2 Data frames 

6.2.1 Introduction 

The purpose of the user data frames is to transparently transport the transport blocks between Node B and Serving 
RNC. 

The protocol allows for multiplexing of coordinated dedicated transport channels, with the same transmission time 
interval, onto one transport bearer. 

The transport blocks of all the coordinated DCHs for one transmission time interval are included in one frame. 

SRNC indicates the multiplexing of coordinated dedicated transport channels in the appropriate RNSAP/NBAP 

message. 

6.2.2 UPLINK DATA FRAME 

The structure of the UL DATA FRAME is shown in figure 1 1 . 
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Figure 1 1 : UPLINK DATA FRAME structure 

For the description of the fields see subclause 6.2.4. 

There are as many TFI fields as number of DCH multiplexed in the same transport bearer. 
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The DCHs in the frame sfructure are ordered from the lower DCH id ('first DCH') to the higher DCH id ('last DCH'). 

The size and the number of TBs for each DCH are defined by the correspondent TFI. 

If the TB does not fill an integer number of bytes, then bit padding is used as shown in the figure in order to have the 
octet aligned structure (ex: a TB of 21 bits requires 3 bits of padding). 

There is a CRCI for each TB included in the frame irrespective of the size of the TB, i.e. the CRCI is included also 
when the TB length is zero. If the CRC indicators of one data frame do not fill an integer number of bytes, then bit 
padding is used as shown in the figure in order to have the octet aligned structure (ex. 3 CRCI bits require 5 bits of 
padding, but there are no CRCI bits and no padding, when number TBs is zero). 

The payload CRC is optional, i.e. the whole 2 bytes field may or may not be present in the frame structure 
(this is defined at the setup of the transport bearer). 

6.2.3 DOWNLINK DATA FRAME 

The structure of the DL DATA FRAME is shown in figure 12. 
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Figure 12: DOWNLINK DATA FRAME structure 

For the description of the fields see subclause 6.2.4. 

There are as many TFI fields as number of DCH multiplexed in the same transport bearer. 

The DCHs in the frame structure are ordered from the lower DCH id (Tirst DCH') to the higher DCH id ('last DCH'). 

The size and the number of TBs for each DCH is defined by the correspondent TFI. 



£75/ 



3GPP TS 25.427 version 3.8.0 Release 1 999 19 ETSI TS 1 25 427 V3.8.0 (2001 -09) 

If the TB does not fill an integer number of bytes, then bit padding is used as shown in the figure in order to have the 
octet aligned structure (ex: a TB of 21 bits requires 3 bits of padding). 

The payload CRC is optional, i.e. the whole 2 bytes field may or may not be present in the frame structure 
(this is defined at the setup of the transport bearer). 

6.2.4 Coding of information elements in data frames 

6.2.4.1 Header CRC 

Description: Result of the CRC applied to the remaining part of the header, i.e. from bit of the first byte, (the FT 
field) to the bit (included) of the last byte of the header) with the corresponding generator polynomial: 
G(D) = D^D^+D^+l. See subclause 7.2. 

Field Length: 7 bits. 

6.2.4.2 Frame Type (FT) 

Description: Describes if it is a control frame or a data frame. 
Value range: {0=data, l=control}. 
Field Length: 1 bit. 

6.2.4.3 Connection Frame Number (CFN) 

Description: Indicator as to which radio frame the first data was received on uplink or shall be transmitted on 
downlink. See reference [2]. 

Value range: {0-255}. 

Field length: 8 bits. 

6.2.4.4 Transport Format Indicator (TFI) 

Description: TFI is the local number of the transport format used for the transmission time interval. For information 
about what the transport format includes see 3GPP TS 25.302 [3]. 

Value range: {0-31}. 

Field length: 5 bits. 

6.2.4.5 Quality Estimate (QE) 

Description: The quality estimate is derived from the Transport channel BER [FDD - or Physical channel BER.] 

[FDD - If the DCH FP frame includes TB's for the DCH which was indicated as "selected" with the QE-selector IE in 
the control plane [4] [6], then the QE is the Transport channel BER for the selected DCH. If no Transport channel BER 
is available the QE is the Physical channel BER.] 

[FDD - If the IE QE-Selector equals "non-selected" for all DCHs in the DCH FP frame, then the QE is the Physical 
channel BER.] 

[TDD - If no Transport channel BER is available, then the QE shall be set to 0. This is in particular the case when no 
Transport Blocks have been received. The value of QE will be ignored by the RNC in this case.] 

The quality estimate shall be set to the Transport channel BER [FDD - or Physical channel BER] and be measured in 
the units TrCh_BER_LOG [FDD - and PhCh_BER_LOG respectively] (see [7] and [8]). The quality estimate is needed 
in order to select a transport block when all CRC indications are showing bad (or good) frame. The UL Outer Loop 
Power Control may also use the quality estimate. 

Value range: {0-255}. 
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Granularity: 1. 
Field length: 8 bits. 

6.2.4.6 Transport Block (TB) 

Description: A block of data to be transmitted or received over the air interface. The transport format indicated by the 
TFI describes the transport block length and transport block set size. See 3GPP TS 25.302 [3]. 

Field length: The length of the TB is specified by the TFI. 

6.2.4.7 CRC indicator (CRCI) 

Description: Indicates the correctness/incorrectness of the TB CRC received on the Uu interface. For every transport 
block included in the data frame a CRCI bit will be present, irrespective of the presence of a TB CRC on the Uu 
interface. If no CRC was present on the Uu for a certain TB, the corresponding CRCI bit shall be set to "0". 

Value range: {0=Correct, l=Not Correct}. 

Field length: 1 bit. 

6.2.4.8 Payload CRC 

Description: CRC for the payload. This field is optional. It is the result of the CRC applied to the remaining part of the 
payload, i.e. from the bit 7 of the first byte of the payload to the bit of the byte of the payload before the CRC field, 
with the corresponding generator polynomial: 
G(D) = D"'+D'^+D^+1. See subclause 7.2. 

Field length: 16 bits. 

6.2.4.9 Spare Extension 

Description: Indicates the location where new lEs can in the future be added in a backward compatible way. 
Field length: 0-2 octets. 

6.3 Control frames 
6.3.1 Introduction 

Control frames are used to transport control information between SRNC and Node B. 

On the uplink, these frames are not combined - all frames are passed transparently from Node B to SRNC. On the 
downlink, the same control frame is copied and sent transparently to all the Node Bs from the SRNC. 

The structure of the control frames is shown in the figure 13. 
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Control Frame Type 
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Spare Extension 
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Figure 13: General structure of the control frames 

Control Frame Type defines the type of the control frame. 

The structure of the header and the payload of the control frames is defined in the following subclauses. 

6.3.2 Header structure of the control frames 



6.3.2.1 



Frame CRC 



Description: It is the result of the CRC applied to the remaining part of the frame, i.e. from bit of the first byte of the 
header (the FT field) to bit of the last byte of the payload, with the corresponding generator polynomial: 
G(D) = D^D^+D^+l. See subclause 7.2. 

Field Length: 7 bits. 

6.3.2.2 Frame Type (FT) 

Description: Describes if it is a control frame or a data frame. 
Value range: {0=data, l=control}. 
Field Length: 1 bit. 

6.3.2.3 Control Frame Type 

Description: Indicates the type of the control information (information elements and length) contained in the payload. 
Value The values are defined in table 1 . 
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Table 1 



Control frame type 


Coding 


OUTER LOOP POWER CONTROL 


0000 0001 


TIMING ADJUSTMENT 


0000 0010 


DL SYNCHRONISATION 


0000 0011 


UL SYNCHRONISATION 


0000 0100 


DSCH TFCI SIGNALLING 


0000 0101 


DL NODE SYNCHRONISATION 


0000 0110 


UL NODE SYNCHRONISATION 


0000 0111 


RX TIMING DEVIATION 


0000 1000 


RADIO INTERFACE PARAMETER 
UPDATE 


0000 1001 


TIMING ADVANCE 


0000 1010 



Field length: 8 bits. 

6.3.3 Payload structure and information elements 

6.3.3.1 TIMING ADJUSTMENT 

6.3.3.1.1 Payload structure 

Figure 14 shows the structure of the payload when control frame is used for the timing adjustment. 
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>> 



Payload 



> 



Spare Extension 



0-32 
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Figure 14: Structure of the payload for the TIMING ADJUSTMENT control frame 

6.3.3.1.2 CFN 

The CFN value in the control frame is coded as in subclause 6.2.4.3. 



6.3.3.1.3 



Time of Arrival (ToA) 



Description: Time difference between the arrival of the DL frame with respect to TO A WE (based on the CFN value in 
the frame). 

Value range: {-1280, h-1279.875 msec}. 

Granularity: 125 )is. 

Field length: 16 bits. 
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6.3.3.1.4 Spare Extension 

Description: Indicates the location where new lEs can in the future be added in a backward compatible way. 
Field length: 0-32 octets. 



6.3.3.2 



DL SYNCHRONISATION 



6.3.3.2.1 Payload structure 

Figure 15 shows the structure of the payload when control frame is used for the user plane synchronisation. 

Number 
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Octets 
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Spare Extension 



>» Payload 



0-32 



Figure 15: Structure of the payload for the DL SYNCHRONISATION control frame 

6.3.3.2.2 CFN 

The CFN value in the control frame is coded as in subclause 6.2.4.3. 

6.3.3.2.3 Spare Extension 

The Spare Extension is described in subclause 6.3.3.1.4. 

6.3.3.3 ULSYNCHRONISATOIN 

6.3.3.3.1 Payload structure 

Figure 16 shows the structure of the payload when the control frame is used for the user plane synchronisation (UL). 
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Figure 16: Structure of the UL SYNCHRONISATION control frame 
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6.3.3.3.2 CFN 

The CFN value in the control frame is coded as in subclause 6.2.4.3. 

6.3.3.3.3 Time of Arrival (ToA) 

See subclause 6.3.3.1.3. 

6.3.3.3.4 Spare Extension 

The Spare Extension is described in subclause 6.3.3.1.4. 



6.3.3.4 



[FDD - UL OUTER LOOP POWER CONTROL] 



6.3.3.4.1 Payload structure 

Figure 17 shows the structure of the payload when control frame is used for the UL outer loop power control. 
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0-32 
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Figure 17: Structure of the payload for OUTER LOOP PC control frame 

6.3.3.4.2 SIR Target 

Description: Value (in dB) of the SIR target to be used by the UL inner loop power control. 

SIR Target is given in the unit UL_SIR_TARGET where: 

UL_SIR_TARGET = 000 SIR Target = -8.2 dB 

UL_SIR_TARGET = 001 SIR Target = -8. 1 dB 

UL_SIR_TARGET = 002 SIR Target = -8.0 dB 

UL_SIR_TARGET = 254 SIR Target = 17.2 dB 

UL_SIR_TARGET = 255 SIR Target = 17.3 dB 

Value range: {-8.2. .. 17.3 dB}. 

Granularity: 0.1 dB. 

Field length: 8 bits. 

6.3.3.4.3 Spare Extension 

The Spare Extension is described in subclause 6.3.3.1.4. 

6.3.3.5 DL NODE SYNCHRONISATION 

6.3.3.5.1 Payload structure 

Figure 18 shows the structure of the payload for the DL NODE Synchronisation control frame. 
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Figure 18: Structure of the payload for the DL NODE SYNCHRONISATION control frame 



6.3.3.5.2 



T1 



Description: RNC specific frame number (RFN) that indicates the time when RNC sends the frame through the SAP to 
the transport layer. 

Value range: As defined in subclause 6.3.3.6.2. 

Field length: 24 bits. 

6.3.3.5.3 Spare Extension 

The Spare Extension is described in subclause 6.3.3.1.4. 

6.3.3.6 UL NODE SYNCHRONISATION 

6.3.3.6.1 Payload structure 

The payload of the UL Node synch control frames is shown in figure 19. 
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Figure 19: Structure of the payload for UL NODE SYNCHRONISATION control frame 

6.3.3.6.2 T1 

Description: Tl timer is extracted from the correspondent DL SYNCHRONISATION control frame. 

Value range: {0-40959.875 ms}. 

Granularity: 0.125 ms. 

Field length: 24 bits. 



6.3.3.6.3 



T2 



Description: Node B specific frame number (BFN) that indicates the time when Node B received the correspondent DL 
SYNCHRONISATION control frame through the SAP from the transport layer. 

Value range: {0-40959.875 ms}. 

Granularity: 0.125 ms. 

Field length: 24 bits. 



6.3.3.6.4 



T3 



Description: Node B specific frame number (BFN) that indicates the time when Node B sends the frame through the 
SAP to the transport layer. 

Value range: {0-40959.875 ms}. 
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Granularity: 0.125 ms. 
Field length: 24 bits. 

6.3.3.6.5 Spare Extension 

The Spare Extension is described in subclause 6.3.3.1.4. 

6.3.3.7 [TDD - RX TIMING DEVIATION] 

6.3.3.7.1 Payload structure 

Figure 20 shows the structure of the payload when the control frame is used for the Rx timing deviation. 
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Figure 20: Structure of the payload for RX TIMING DEVIATION control frame 

6.3.3.7.2 Rx Timing Deviation 

Description: Measured Rx Timing deviation as a basis for timing advance. 
Value range: {-256, ..,h-256 chips}. 

{N*4 -256} chips < RxTiming Deviation < {(Nh-1)*4 -256} chips 

With N = 0,1,.., 127 
Granularity: 4 chips. 
Field length: 7 bits. 

6.3.3.7.3 Spare Extension 

The Spare Extension is described in subclause 6.3.3.1.4. 

6.3.3.7.4 CFN 

The CFN value in the control frame is the CFN when the RX timing deviation was measured. It is coded as in subclause 
6.2.4.3. 



6.3.3.8 



[FDD - DSCH TFCI SIGNALLING] 



6.3.3.8.1 Payload structure 

Figure 21 shows the structure of the payload when the control frame is used for signalling TFCI (field 2) bits. 
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Figure 21 : Structure of the payload for the DSCH TFCI SIGNALLING control frame 

6.3.3.8.2 TFCI (field 2) 

Description: TFCI (field 2) is as described in [4], it takes the same values as the TFCI(field 2) which is transmitted 
over the Uu interface. 

Value range: {0-1023} 

Field length: 10 bits 

6.3.3.8.3 Spare Extension 

The Spare Extension is described in subclause 6.3.3.1.4. 

6.3.3.9 [FDD - RADIO INTERFACE PARAMETER UPDATE] 



6.3.3.9.1 



Payload structure 



Figure 22 shows the structure of the payload when the control frame is used for signalling radio interface parameter 
updates. 
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Figure 22: Structure of the payload for the RADIO INTERFACE PARAMETER UPDATE control frame 

6.3.3.9.2 Radio Interface Parameter Update flags 

Description: Contains flags indicating which information is present in this control frame. 

Value range: 

Bit 0: Indicates if the 3'^'' byte of the control frame payload contains a CFN (1) or not (0); 

Bit 1: Indicates if the 4* byte (bits 0-4) of the control frame payload contains a TPC PO (1) or not (0); 

Bit 2-15: Set to (0): reserved in this user plane revision. Any indicated flags shall be ignored by the receiver. 

Field length: 16 bits. 

6.3.3.9.3 TPC Power Offset 

Description: Power offset to be applied in the DL between the DPDCH information and the TPC bits on the DPCCH. 
Value range: {0-7.75 dB}. 
Granularity: 0.25 dB. 
Field length: 5 bits. 

6.3.3.9.4 Spare Extension 

The Spare Extension is described in subclause 6.3.3.1.4. 

6.3.3.1 [TDD - TIMING ADVANCE] 

6.3.3.10.1 Payload structure 

Figure 23 shows the structure of the payload when the control frame is used for timing advance. 



£75/ 



3GPP TS 25.427 version 3.8.0 Release 1999 



30 



ETSI TS 125 427 V3.8.0 (2001-09) 



Number of 
Octets 



CFN 



Spare 



TA 



Spare Extension 



1 

1 
0-32 



">> 



> Payload 



^ 



Figure 23: Structure of the TIMING ADVANCE control frame 

6.3.3.10.2 CFN 

The CFN value in the control frame is the frame that the timing advance will occur and is coded as in subclause 6.2.4.3. 

6.3.3.10.3 TA 

Description: UE applied UL timing advance adjustment. 
Value range: {0-252 chips}. 
Granularity: 4 chips. 
Field length: 6 bits. 

6.3.3.10.4 Spare Extension 

The Spare Extension is described in subclause 6.3.3.1.4. 

7 Handling of Unknown, Unforeseen and Erroneous 

Protocol Data 



7.1 



General 



A Frame Protocol frame with illegal or not comprehended parameter value shall be ignored. Frame protocol frames sent 
with a CFN in which the radio resources assigned to the associated Tub data port are not available, shall be ignored. 

Frame protocol data frames with CFN value that does not fulfil the requirement set in clause [FDD - 4.2.14 of [9]] 
[TDD - 4.2.12 of [10]], shall be ignored 



7.2 



Error detection 



Error detection is provided on frames through a Cyclic Redundancy Check. The length of the CRC for the payload is 
16 bits and for the frame header and control frames it is 7 bits. 



7.2.1 



CRC Calculation 



The parity bits are generated by one of the following cyclic generator polynomials: 

gcRci6(D) = D'* + D'^ + D^+l 



gcRC7(D) = D^ + D" + DV 1 
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Denote the bits in a frame by Oj , aj , ftlg , . . . , a^ , and the parity bits by p^,P2,Pj,,. .., Pi ■ A, is the length of a 
protected data and L, is 16 or 7 depending on the CRC length. 

The encoding is performed in a systematic form, which means that in GF(2), the polynomial for the payload 

ap^'^'' + a^D^^'' +... + a^p'^ + p.D'' + pp'' + ... + p^p' + p,^ 

yields a remainder equal to when divided by gcRcieCD) and the polynomial for the header and control frame 

ap^^^ +ap^^^ + ... + a^D' + pP^ + pP^ + ... + pP' + p^ 

yields a remainder equal to when divided by gcRC7(D)- If A. = , Pi = P2 — P3— '" — Pi — • 

7.2.1 .1 Relation between input and output of the Cyclic Redundancy Check 

The bits after CRC attachment are denoted by b^,b2,b^,. ..,bQ , where Bj=Af¥Li. 
The parity bits for the payload are attached at the end of the frame: 
b^=a^ k= 1,2,3, ...,A; 

^k = P(k-A,)^ = ^i+ l,A, + 2,A, + 3, ...,A, + L/ 

The parity bits for the frame header and the control frames are attached at the beginning of the frame: 

b^=p,^ k = 1,2,3, ...,L, 

^k = ^ik-Li) ^ = A- + 1, Li + 2, L, + 3, ..., Li+Ai 
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